QRZ! Ham Radio 1/QRZ Ham Radio Callsign Database - December 1993.iso/ucsd/packet/tcpip/mac/radcnfgs.hqx/TCP_IP for the Mac/Docs/MacIP Specs 1

Text File | 1993-01-04 | 30.4 KB | 679 lines

Draft Proposal for the Specification of IP Datagrams transported over
AppleTalk Networks (MacIP)

Status of this Memo

This is an initial attempt to document the current "pseudo standard"
referred to as MacIP.  This document does not attempt to correct any of
the problems or shortcomings of the protocol and implementations.  It
simply documents the current state of the art.

1  Introduction

The goal of the MacIP architecture is to provide access to TCP/IP-based
protocols for the Apple Macintosh computers not directly connected to
Ethernet.

Traditionally access to IP protocols from a host computer required a
direct connection to a high speed network such as Ethernet.  Direct
Ethernet connection was not possible for the original versions of the
Macintosh computer.  The early Macintoshes did, however, come equipped
for LocalTalk, Apple Computer's medium speed network specification.
Every Macintosh comes from the factory with the hardware and software
necessary to use the LocalTalk network.  There is also a well defined
set of protocols, AppleTalk [1], which roughly cover the ISO seven layer
model.

This paper describes the present day method of using the existing
LocalTalk network to transport TCP/IP packets to and from an IP network
with the aid of a gateway, allowing any Macintosh computer to be a host
on an IP network.  For the remainder of this paper, the term gateway
will refer to a device which provides this service.

Transporting IP over an AppleTalk Network

Transport of IP packets over LocalTalk is achieved by encapsulating them
in Datagram Delivery Protocol (DDP) datagrams and sending them to a
gateway for de-encapsulation and delivery to the IP network.  The
typical gateway is a two port device, with one port on a LocalTalk
network and one port on an Ethernet.  When the packet is received by the
gateway's LocalTalk port, the DDP header is stripped and a proper
Ethernet header prepended.  The packet is then sent out through the
Ethernet port.  Ethernet-based IP packets bound for a Macintosh on
LocalTalk go though a similar sequence of events.  The Ethernet header
is removed and the packet is encapsulated in a DDP datagram and then
sent to the LocalTalk network.

In addition to encapsulation, there are addressing and address
resolution issues which the gateway must handle on both networks.
This document is purposefully confined to the description of the two
port gateway, where one port is connected to an AppleTalk network and
one port is connected to a Ethernet IP network.  Note that the AppleTalk
port of the gateway does not need to be restricted to LocalTalk as
AppleTalk may the transported via other media, such as Ethernet.
Address Resolution

IP address resolution is required on both sides of the gateway.  On the
Ethernet side traditional Ethernet Address Resolution Protocol (ARP) is
required to map an IP addresses to an Ethernet addresses [2].

On the AppleTalk side the gateway must  map an IP address to a AppleTalk
address.  Two methods exist for performing IP address resolution on the
AppleTalk network.  Each has some advantages over the other, and both
have been used in different implementations of the MacIP architecture.
A proper implementation of the gateway should support both.

The first method uses the DDP datagram protocol and functions
essentially like the Ethernet ARP protocol.  This is referred to as DDP
ARP.  The second method uses the AppleTalk Name Binding Protocol, (NBP).
It takes advantage of this protocol's ability to span AppleTalk
networks.  This is referred to as NBP ARP.

For historical reasons, DDP ARP should be supported by MacIP gateways,
although NBP ARP is more widely used, and offers certain advantages, as
discussed below.

2  Architecture

2.1  Overview of the Current Solution

Current implementations of the MacIP architecture provide both a gateway
and a client/server system between the Macintosh host and the gateway.
The gateway performs encapsulation and address mapping between the
AppleTalk and IP networks, as well as various server functions.  The
architecture requires software on the Macintosh to implement the client
side of this architecture, as well as the basic IP host functions.
The current implementations provide Macintosh computers with access to
TCP/IP protocols.  There are also provisions for automatic assignment of
IP addresses and discovery of well known IP addresses such as name
servers.

2.2  Encapsulation

TCP/IP packets are encapsulated in DDP packets of a special DDP type.
The source and destination sockets of the packet are specified as a
special, fixed "MacIP" socket.
The TCP/IP packet is stripped of any media headers and then sent in the
data portion of the DDP packet described above.
Due to the limited size of AppleTalk DDP packets, the Maximum Transfer
Unit (MTU) of the AppleTalk network is smaller than that of EtherTalk.
The smaller MTU size of AppleTalk implies that gateways must fragment
packets coming from Ethernet which are larger than the AppleTalk MTU.
Some older implementations of MacIP gateways do not fragment large IP
packets from Ethernet.  They are quietly dropped instead.  This behavior
is not correct.  All implementations of MacIP on the Macintosh must be
able to deal with inbound fragmented IP packets.

Using DDP versus LLAP

As a digression, it is worth discussing why DDP is used as a transport
instead of the Link layer protocol, LocalTalk Link Access Protocol
(LLAP), similar to what is done on Ethernet networks.  A solid argument
can be formed which states that by using LLAP, you could model MacIP, or
IP on AppleTalk, directly after the evolution of IP on Ethernet.
Taking this approach would lead you to use an ARP nearly identical to
the ARP used on Ethernet and encapsulate IP packets in a special LAP
type.

While this technique would work fine, these special packets would not be
"routable" by any normal AppleTalk router.  This limits the IP on
AppleTalk network to a single wire.  The initial design allowed for
transport of the encapsulated IP packets over an arbitrary AppleTalk
network.  Using DDP for transport allows the packets to be routed by any
AppleTalk router with no knowledge of IP, which makes the system more
expandable and flexible.

2.3  Addressing

A Macintosh host wishing to send an IP packet needs to determine the
local IP destination address.  A decision is initially made as to
whether the packet is for this IP network. If it is not (the general
case for packets from a Macintosh), the local destination IP address is
set to the gateway's IP address.  Once the local destination IP address
is determined then address resolution is performed to determine the
AppleTalk address to which the packet will be sent.

It is safe to skip the initial is this packet for my network test and
simply ARP for the destination IP address, as all of the current gateway
implementation will proxy ARP for addresses outside of their network
(i.e. they will reply on behalf  of addresses outside the range of
addresses assigned to the AppleTalk network).

The issue of broadcast address mapping is somewhat ill defined.  It is
safe, however, to say that encapsulated IP packets destined for the IP
broadcast address should have the DDP datagram addressed to the LLAP
broadcast node, 255.

Conversely, when receiving encapsulated IP packets sent to the LLAP
broadcast node, these should be treated as wire level broadcast packets
and not routed.  It is assumed that this should be a function of the
AppleTalk and IP router portions of the MacIP gateway.  It follows that
directed broadcasts should be noticed and handled in the appropriate
manner [4].

2.4  Address Resolution

As noted above, there are two styles of AppleTalk-based IP address
resolution used by current MacIP implementations.

DDP ARP

The initial gateway implementations of MacIP used the DDP ARP method.
This method closely follows the protocol and methodology of Ethernet ARP
[2].

DDP ARP packets are broadcast on the local AppleTalk segment and are not
routed.  Therefore, the DDP ARP method will only resolve addresses of
Macintosh hosts on the AppleTalk segment directly connected to the
gateway.

NBP ARP

The NBP ARP technique began with the release of Stanford's KIP gateway
software.  This address resolution technique is a great deal more
flexible than the DDP ARP technique and allows for dynamic assignment of
IP addresses.

NBP ARP uses the AppleTalk NBP to register IP addresses in the AppleTalk
name space.

When a node (or a gateway) wishes to ARP for an IP address, it simply
uses the NBP lookup function to look for the IP address.  If the address
is active, the node which has registered the IP address will
automatically answer with its AppleTalk address. This completes the ARP
function and provides a full destination AppleTalk address.

It is very important to note that NBP has a concept of named
administrative domains know as zones.  Names are only guaranteed to be
unique inside of one zone.  (There is also a shorthand to indicate "this
zone".)  Because of this there is an implied mapping between the zone of
which the gateway is a member and the collection of Macintosh based IP
addresses accessible to the gateway.  This issue is complicated somewhat
by the issue of forwarding versus subnetting and will be described more
fully in that section, below.

In contrast to DDP ARP, which is restricted to one AppleTalk wire due to
its use of local broadcasts, NBP ARP can reach Macintoshes on other
AppleTalk networks.  The NBP protocol has provisions for propagating NBP
requests through gateways.  As long as a node is in the same NBP zone as
the gateway, the NBP ARP method will properly resolve addresses.

Additionally, using NBP ARP creates an object which is visible to all
native AppleTalk devices, which can aid diagnostics.  Finally, employing
the NBP protocol's provisions for registration, and lookups for multiple
objects with one request makes dynamic address assignment possible.

2.5  Gateways

The MacIP Gateway provides several functions in the gateway process.  In
addition to sending packets back and forth between the two networks and
supporting address translation, or ARP, it provides a simple server
function for distributing important IP addresses and assigning IP
addresses to Macintosh hosts.

Macintosh hosts use the NBP protocol to discover a MacIP gateway.  The
gateway registers a Network Visible Entity (NVE) of type "IPGATEWAY",
using its IP address in dot notation as its object name.  When a
Macintosh wants to access a MacIP gateway service, it performs a lookup
for all NVEs of type "IPGATEWAY".  Generally only one gateway will
respond and the Macintosh will record its AppleTalk address for future
use.

As an implementation note a Macintosh should be able to perform this
"gateway lookup" at any time, as the gateway may go down and reappear at
a difference AppleTalk address.  A good technique would be to lookup the
gateway anew whenever the gateway does not answer.  (This would be
indicated by an error at the DDP level when using LocalTalk.)

The MacIP gateway implements an AppleTalk Transaction Protocol (ATP)
based protocol for performing simple functions.  There are two currently
defined functions which this protocol.  These are get server info and
assign IP address.

The get server info function returns a list of common server IP
addresses, such as name server, file server and the broadcast address.
These are defined as part of the gateway's configuration and simply
passed on via the protocol without interpretation.

The assign IP address function returns an IP address which can be used
by the Macintosh host to communicate with other IP hosts.  The gateway
is configured with a range of addresses for dynamic assignment and
maintains a table of these assigned addresses, periodically checking
that they are still in use.  Assigned addresses are maintained for a
period of time so that if a Macintosh is rebooted and asks for an
address again, it will receive the same IP address.

It is important to note that IP addresses assigned via the gateway ATP
protocol must be registered and resolved using the NBP ARP technique.
The DDP ARP technique is only valid for use with statically assigned IP
addresses, as there is no protocol for registration or determining
which addresses are assigned.

2.6  TCP/IP Code on the Macintosh

*** TO BE WRITTEN ***

3  Protocol

3.1  Encapsulation Technique

TCP/IP packets are encapsulated in DDP packets of type 22 (decimal).
The source and destination sockets of the packet are 72 (decimal) by
convention.  There is no requirement as to the use of short or long
headers.  The packets can be run over any valid AppleTalk media,
including Ethernet.

When encapsulating a packet bound for AppleTalk, the TCP/IP packet is
stripped of any media headers and then sent as the data portion of the
DDP packet.

The AppleTalk DDP protocol limits the data size of a DDP packet to 586
bytes, which is then the MTU of the AppleTalk network when transporting
IP datagrams.

The Ethernet network has an MTU size of 1486 bytes.  The smaller MTU
size of AppleTalk implies that gateways must fragment Ethernet packets
bound for AppleTalk which are larger than the AppleTalk MTU [3].
^A
3.2  Addressing Styles

The original SEAGate gateway and several early versions of the FastPath
gateway code provided access to the Ethernet IP network by treating the
AppleTalk network as an IP subnet [6, 7].

The KIP code does not form a subnet but rather forwards IP packets to
and from the Ethernet using proxy ARP.

There are two alternative approaches to integrating an AppleTalk network
into an IP network.  One approach involves treating the AppleTalk
network as an IP subnet, with the MacIP gateway assuming the role of  an
IP  router.  The alternative is to allocate a small range of addresses
from the IP network to the AppleTalk network.  In this case, the MacIP
gateway forwards IP packets to and from AppleTalk.

The forwarding method is conceptually easier, and, thus, simpler to
configure.  No large range of subnet addresses needs to be calculated
and allocated to the AppleTalk network.

The subnetting method is more difficult conceptually and, hence, harder
for a novice to configure.  It is, however,  more consistent with the
requirements of many large sites, and can be more practical in
complicated networks.  This is especially true if the MacIP gateway will
emit Routing Information Protocol (RIP, [5]) packets to inform the
Ethernet network of the MacIP AppleTalk subnet.

Subnetting

Subnetting via the MacIP protocol is straightforward from the
perspective of IP routing.  The gateway has two IP addresses (one for
each port M-P Ethernet and AppleTalk) and defines the AppleTalk network to
be a subnet of the IP network.  This definition is done with a network
number and a subnet mask.

According to the defined IP gateway specification [4] the MacIP gateway
should only answer ARP requests for its own IP address.  No proxy ARP
function should be performed.  This requires that the TCP/IP hosts on
both sides of the gateway be informed of the gateway's presence.  This
can be done via static routing tables or via the RIP protocol.  A
conservative RIP implementation1 in the MacIP gateway is recommended for
this function.

Forwarding

When forwarding with the MacIP architecture, the AppleTalk network is
treated as an extension of the Ethernet IP network.  This is done by
specifying a range of IP addresses which are allocated to the AppleTalk
network, and to which the MacIP gateway will "forward" packets from the
Ethernet.  When a host on the Ethernet ARPs for an IP address which is
in this range, the gateway will answer, performing the proxy ARP
function.  When a host on the AppleTalk ARPs for an IP address outside
of the range, the a gateway will reply to the ARP, again performing the
proxy ARP function.  The address resolution on AppleTalk can be done
using the NBP or DDP technique.  Dynamic assignment of IP addresses on
the AppleTalk side can be accomplished with the gateway ATP protocol;
see below.

3.3  Address Resolution Styles

DDP ARP

DDP ARP uses the same packet definition as Ethernet ARP but defines a
new hardware address type, and uses DDP for transport.  This new address
type is four (4) bytes long and is comprised of a concatenated AppleTalk
network number (2 bytes), node number (1 byte), and socket (1 byte).
The mechanics of the ARP transaction using DDP are the same as those on
Ethernet.  This implies that the gateway function also contains an cache
of resolved address translations.

NBP ARP

As stated above, NBP ARP uses the AppleTalk NBP protocol.  Each active
IP address on the AppleTalk is registered as an NVE.  Its existence can
be queried and uniqueness guaranteed and defended using the simple
protocol defined by NBP.

When registering a name and type with NBP a check is made for duplicate
registrations on the network.  Having determined no duplicates exist,
NBP then will defend against future registrations of the same name.
This "atomic" attribute of NBP guarantees the uniqueness of IP addresses
registered this way.

When a host has decided what its IP address will be, it registers this
address as an ASCII name comprised of the IP address in its printed
form, using dot notation (i.e., "192.45.17.1").  Each NVE also has a
type defined by an ASCII string.  The registered IP addresses have the
type "IPADDRESS".

Mapping a Zone to an IP Subnet

The NBP ARP method implies a relationship between the group of IP
addresses which reside on the AppleTalk network and the zone name of the
LocalTalk network connected to the gateway.

The implied relationship between the LocalTalk network's zone name and
the IP subnet can be exploited to implement directed broadcasts.  If the
gateway receives a directed broadcast for the IP subnet, it could send
it out as a directed broadcast to each network in the zone, in the same
manner as NBP handles an NBP bridge request.  If the gateway is
forwarding, any IP broadcasts on the Ethernet could be forwarded in the
same manner.

Using a Gateway From Another Zone

Because the gateway uses NBP to register itself, it is possible to look
for a gateway in any zone.  If Macintosh is in zone A, it can look for a
gateway in zone B and then communicate with this gateway via the gateway
ATP protocol.  This will allow the Macintosh to obtain an IP address and
communicate with the gateway.

The gateway maintains its table of assigned dynamic addresses by
periodically sending out NBP confirm requests.  These requests are send
directly to the host which was assigned the address.  Macintosh hosts
which are in a different zone than the gateway will respond correctly to
these confirm requests, and hence keep their address assignments alive.
While this allows a Macintosh in a different zone to use a MacIP
gateway, it breaks the relationship between the zone name and the
assigned IP addresses.  A second Macintosh, within the zone, might
attempt to ARP for this out-of-zone machine M-P or, far worse, attempt to
claim the same IP address, yet the first Macintosh would not see the NBP
lookups.  Although this may work for communication with non-AppleTalk IP
hosts, it will not allow future enhancement to take advantage of the
"zone to subnet/forward group" relationship.

3.4  Dynamic IP Address Assignment

Dynamic IP address assignment is accomplished in the MacIP protocol by
designating the gateway as an IP address server.  The MacIP gateway is
given the task of handing out IP addresses to Macintosh hosts and
maintaining a table of assigned addresses.

Having located the MacIP gateway, the Macintosh host requests an IP
address.  The gateway responds with an address if one is available.  If
no addresses are available (generally because they are all in use) the
gateway responds with an error.  If an address is successfully obtained,
it is then the responsibility of the Macintosh to attempt to register
this address with NBP.

In order to properly maintain the table of assigned addresses, the
gateway periodically sends out an NBP lookup for all objects of type
"IPADDRESS".  Responses are matched against entries in the table.
Responses not found in the table are added, allowing for static
assignment of addresses within the range.  Entries in the table for
which no responses are received are aged and eventually time out and are
removed.

When the gateway is first started, an initial lookup is done to prime
the table with any existing assignments.  Note that since DDP ARP has no
protocol for performing the same operation, it is not appropriate for
use with dynamic IP address assignment.

In an implementation of a MacIP gateway, the table of assigned IP
addresses can be used to support the ARP function.

3.5  The Gateway ATP Protocol

The Gateway ATP Protocol is a simple request-response protocol based on
the AppleTalk ATP protocol.  It can be supported without a requiring
full ATP implementation.

ATP requests are done using the exactly once, or "XO" type transaction.
It is not necessary for the gateway to completely implement the "XO"
semantic.  Macintosh hosts should, however use it when making requests.
The user data portion of the ATP request is not used.  Instead, the
first four (4) bytes of the request data form a long-word integer
request number.  The byte ordering of the value is big-endian (most
significant byte first).  The response packet is a structure consisting
of a sequence of four (4) byte integers, followed by a byte array
containing ASCII error text.  The byte ordering of the integers in the
response packet is also big-endian.  The ASCII error text is only valid
if the return code is negative when interpreted as a signed, 32 bit
quantity.

3.6  A Sample Transaction Stream

Below is a sample "transaction stream" designed to illustrate the use of
the gateway ATP protocol and the use of NBP to perform the ARP function
on AppleTalk.

Overview:

A Macintosh host wishes to find a MacIP gateway, obtain an IP address

Received: from iggppserv.igg.tno.nl by iggcis1.igg.tno.nl (4.1/SMI-4.1)    id AA16360; Wed, 30 Dec 92 05:12:12 +0100
Received: by iggppserv.igg.tno.nl (4.1/SMI-4.1)    id AA23502; Wed, 30 Dec 92 05:12:12 +0100
Resent-Date: Tue, 29 Dec 1992 19:37:11 -0800
Resent-From: root@iggppserv (System Manager)
Resent-Message-Id: <[e-mail]>
Resent-To: [e-mail]
Return-Path: <[e-mail]>
Received: from ITI.TNO.NL (tnoit1) by iggppserv.igg.tno.nl (4.1/SMI-4.1)    id AA23455; Wed, 30 Dec 92 05:06:10 +0100
Received: from TNO.NL by ITI.TNO.NL; Wed, 30 Dec 92 04:54 MET
Received: from HEARNVAX.nic.SURFnet.nl by TNO.NL; Wed, 30 Dec 92 04:37 MET
Received: from netcom.netcom.com by HEARNVAX.nic.SURFnet.nl with PMDF#10216; Wed, 30 Dec 1992 04:39 MET
Received: from netcom.netcom.com by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA23360; Tue, 29 Dec 92 19:35:57 -0800
Date: Tue, 29 Dec 1992 19:37:11 -0800
From: [e-mail]
Subject: MacIP Spec
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Attachments: :Macintosh HD:663:MacIP_Spec_#0.4.txt:
X-Envelope-To: adam@IGGPPSERV
Status: RO

from that gateway and open a TCP session with a host on Ethernet.

    Macintosh                Gateway
Step 1:
Perform NBP Lookup for object "=" (wildcard), type "IPGATEWAY".
Answers lookup with object "192.31.222.1", the gateway's IP address.
Step 2:
Send gateway ATP transaction get server info to gateway.
Respond with IP addresses as configured.
Step 3:
Send gateway ATP transaction assign IP address to gateway.
Look in table of assigned addresses, using source AppleTalk address as
key.  If entry found, respond with previously assigned address.  If no
entry found, create new entry and assign new IP address.  Respond.
Step 4:
Register assigned address as an NBP NVE, the  object being the IP
address in "dot-notation", and with type "IPADDRESS".
Step 5:
IP code wants to send TCP SYN to IP address 18.1.1.1;  Either default to
18.1.1.1 as destination IP or decide that gateway is destination IP.
Perform NBP ARP for destination address, type "IPADDRESS".
Respond to ARP for either gateway's IP address or proxy ARP for true
destination address.
Step 6:
Encapsulate TCP SYN in DDP packet and send to gateway.
Remove DDP header, add Ethernet header, perform Ethernet ARP function,
if appropriate, and send packet on Ethernet
Destination host (18.1.1.1) responds with SYN.  Remove Ethernet header,
add DDP header, perform ARP function for destination address.  Send DDP
header.
The last few steps are performed repeatedly.

3.7  Closure: Why It Works

Bill Croft described the NBP ARP technique in the documentation which is
included with the KIP source code.

Lookups at gateway startup time

When the MacIP gateway starts up, it does an initial lookup for all
objects of type "IPADDRESS".  If any responses are received, they are
added to a table of assigned addresses.  In this way the gateway
recovers any state which may be lost if the gateway crashes or is
restarted.

Defending addresses

When a Macintosh is dynamically assigned an address or wishes to use a
statically assigned one, it first attempts to register its address using
NBP.  This operation has two effects.  First, it determines that the
address is not currently in use.  Then, it secures the use of this
address ensuring the Macintosh's NBP software will respond to any
lookups for this address by other nodes which may be performing the same
operation.  This sequence is equivalent to an atomic test and set
operation to ensure that addresses are only in use by one Macintosh at
one time.

4  History

4.1  The Original "SEAGate" Gateway code

The first "AppleTalk-to-Ethernet" gateway was created at Stanford
University around 1985 and was known as the M-TStanford Ethernet AppleTalk
Gateway", or SEAGate.  It was comprised of a Multibus backplane, a 68000
CPU card and a simple LocalTalk (then known as "AppleBus") interface
card.

The SEAGate source code and design documents were freely available to
members of the Internet community.  The initial design provided for
simple transport of encapsulated IP datagrams from AppleTalk-based
Macintosh computers to Ethernet based IP hosts.  The DDP ARP protocol
was used and gateway configuration was simple and primitive.

A port of the MIT PC/IP code (a TCP/IP implementation for IBM PCs) to
the Macintosh was made by several people at Dartmouth College.  The
first application was a simple Telnet application.

The initial Kinetics FastPath was essentially a commercialized version
of the Stanford SEAGate and ran modified SEAGate gateway code.  The
initial FastPaths were shipped with the Dartmouth Telnet application.

4.2  The "KIP" Gateway Code

The original KIP software was an enhanced version of the original
SEAGate software.  Over time it was enhanced and gained the ability to
do AppleTalk routing and encapsulation of AppleTalk packets inside UDP
datagrams.

The KIP software also added the ability to do centralized administration
of multiple gateways.  This, combined with the ability to transport
AppleTalk packets to UNIX hosts by encapsulating them in UDP packets
gave rise to an AppleTalk implementation for UNIX known as the Columbia
AppleTalk Package, or CAP software.  This software currently allows both
file sharing and printing to and from UNIX hosts and Macintosh
computers.

4.3  NCSA's TCP/Telnet Software

The National Center for Super Computer Application (NCSA) has put into
the public domain a Macintosh application which contains an
implementation of TCP/IP which supports the MacIP protocol.  This
application was designed to be a terminal emulation program supporting
the TELNET protocol allowing terminal access to TCP/IP host computers.

The NCSA TCP/Telnet software supports static and Gateway based
assignment of IP addresses, using the gateway ATP protocol.  Both NBP
and DDP ARP are supported.

This is currently the most widely distributed version of MacIP software
and is available in source form.

InterCon, Inc. of Reston, Va. has made a greatly enhanced version of the
this software (TCP/Connect) available as a commercial application.

4.4  Apple's MacTCP driver

Full Featured IP/UDP/TCP

Apple released V1.0 of the MacTCP drivers which provide TCP/IP protocols
for Macintosh computers.  This software provides a consistent
application interface to the TCP/IP software layer and moves the
protocol software out of the Applications and into the Macintosh system
software.

In addition to the basic TCP and UDP services, basic Domain Name System
(DNS) resolver capabilities are supplied.

Supports Gateway ATP Protocol and NBP ARP

The MacTCP drivers support a portion of the MacIP protocol.  This allows
Macintosh computers to communicate with TCP/IP hosts via the AppleTalk
network.

The V1.0 MacTCP drivers support the gateway ATP protocol as well as the
NBP ARP protocol.  Static and Gateway (server) based address assignment
(via the gateway protocol) are supported.  No support is available for
the older DDP ARP protocol.

5  Definitions

5.1  AppleTalk Protocol constants

MacIP MTU                        516 bytes
DDP constants
    MacIP packet type                22 (decimal)
    DDP ARP packet type            23 (decimal)
DDP ARP constants
    AppleTalk address type            3 (decimal)
NBP constants
    gateway object type            IPGATEWAY
    registered IP address object type        IPADDRESS

5.2  Gateway ATP Protocol Constants

ATP request command codes
    ASSIGN    assign IP address        1
    NAME    name server        2 (obsolete)
    SERVER    get server info        3
ATP response codes
    SUCCESS                    same as request code
    ERROR                    -1

6  Acknowledgements

Bill Croft - documents provided with the KIP code
Gauge Paulson and Tim K. - NCSA source code
John Romkey - original PC/IP source code
Tim Maroney and ? - port of PC/IP to Macintosh

References

[1]    Sidhu, G., Andrews, R., and Oppenheimer, A., Apple Computer,
Inside AppleTalk, Addison-Wesley Publishing Company, Inc., Reading, MA,
1989.

[2]    Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826,
Symbolics, September 1982.

[3]    Postel J., "Internet Protocol", RFC-791, USC Information Sciences
Institute, September 1981.

[4]    Brandon, R., and Postel, J., "Requirements for Internet Gateways",
RFC-1009, USC Information Sciences Institute, June 1987.

[5]    Hendrick, C., "Routing Information Protocol", RFC-1058, June 1988.

[6]    Mogul, J., "Internet Subnets", RFC-917, Stanford University,
October 1984.

[7]    Mogul, J., and Postel, J., "Internet Standard Subnetting
Procedure", RFC-950, Stanford University, August 1985.

1 In a conservative RIP implementation only the AppleTalk side of the
gateway should be advertised.  No routing information obtained via RIP
should be propagated.